update docs - softserial limit by RomanLut · Pull Request #11771 · iNavFlight/inav

RomanLut · 2026-08-08T15:49:11Z

Software serial does not limit to 19200 since version 5 or so. Fixed misleading docs.

github-actions · 2026-08-08T15:49:19Z

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.
maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

This is an automated suggestion to help route contributions to the appropriate branch.

qodo-code-review · 2026-08-08T15:49:46Z

PR Summary by Qodo

Fix telemetry docs: remove outdated softserial baud-rate limits

📝 Documentation 🕐 Less than 5 minutes

AI Description

• Remove outdated MAVLink softserial 19200 baud requirement from telemetry documentation.
• Remove incorrect IBUS softserial 19200 baud-limit note; keep only fixed 115200 baud requirement.

High-Level Assessment

The following are alternative approaches to this PR:

1. Add a short version/target note instead of removing constraints

➕ Clarifies when/why older softserial baud limitations applied
➕ Reduces risk of readers assuming all targets can reliably run 115200 on any softserial implementation
➖ Requires accurate historical/version and per-target details
➖ Adds maintenance burden as serial implementations evolve

Recommendation: The PR’s approach (removing inaccurate hard limits) is appropriate and low risk. If confusion persists, consider adding a brief note that achievable baud rates can vary by target/serial implementation, rather than stating a universal limit.

Files changed (1) +2 / -2

Documentation (1) +2 / -2

Telemetry.mdRemove obsolete softserial baud-limit statements for MAVLink and IBUS +2/-2

Remove obsolete softserial baud-limit statements for MAVLink and IBUS

• Updates the MAVLink section to remove the claim that softserial requires 19200 baud. Updates the IBUS section to remove the statement that softserial is limited to 19200 baud, leaving only the fixed 115200 baud requirement.

docs/Telemetry.md

qodo-code-review · 2026-08-08T15:51:34Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~MAVLink not transmit-only~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

docs/Telemetry.md states MAVLink in INAV is “transmit-only”, but the current MAVLink telemetry
implementation reads and processes incoming MAVLink messages (missions/params/RC override/etc). This
misleads users about MAVLink capabilities and is in-scope because the PR edited this sentence but
kept the incorrect claim.

Code

docs/Telemetry.md[209]

+MAVLink implementation in INAV is transmit-only, is usable at low baud rates. MAVLink V1 and V2 are supported.

Evidence
The documentation explicitly claims transmit-only, while the implementation explicitly reads from
the MAVLink serial port and handles multiple incoming message types, so the doc statement is
incorrect.
docs/Telemetry.md[205-210]
src/main/telemetry/mavlink.c[1388-1433]
src/main/telemetry/mavlink.c[1444-1456]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`docs/Telemetry.md` says MAVLink is transmit-only, but the implementation processes inbound MAVLink messages. This is incorrect documentation and can lead users to wrong configuration/expectations.
### Issue Context
The telemetry MAVLink code contains an explicit receive loop and dispatches received message IDs.
### Fix Focus Areas
- docs/Telemetry.md[205-210]
- src/main/telemetry/mavlink.c[1388-1433]
- src/main/telemetry/mavlink.c[1444-1456]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~MAVLink not transmit-only~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

docs/Telemetry.md states MAVLink in INAV is “transmit-only”, but the current MAVLink telemetry
implementation reads and processes incoming MAVLink messages (missions/params/RC override/etc). This
misleads users about MAVLink capabilities and is in-scope because the PR edited this sentence but
kept the incorrect claim.

Code

docs/Telemetry.md[209]

+MAVLink implementation in INAV is transmit-only, is usable at low baud rates. MAVLink V1 and V2 are supported.

Evidence
The documentation explicitly claims transmit-only, while the implementation explicitly reads from
the MAVLink serial port and handles multiple incoming message types, so the doc statement is
incorrect.
docs/Telemetry.md[205-210]
src/main/telemetry/mavlink.c[1388-1433]
src/main/telemetry/mavlink.c[1444-1456]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`docs/Telemetry.md` says MAVLink is transmit-only, but the implementation processes inbound MAVLink messages. This is incorrect documentation and can lead users to wrong configuration/expectations.
### Issue Context
The telemetry MAVLink code contains an explicit receive loop and dispatches received message IDs.
### Fix Focus Areas
- docs/Telemetry.md[205-210]
- src/main/telemetry/mavlink.c[1388-1433]
- src/main/telemetry/mavlink.c[1444-1456]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ~~Softserial limit docs conflict~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

docs/Telemetry.md removes the “softserial limited to 19200” guidance, but other docs still claim
SoftSerial is capped at 19200, creating contradictory configuration guidance. The SoftSerial
implementation appears to accept an arbitrary baud (no explicit 19200 clamp), so the remaining
“19200 limit” statements are likely misleading or at least need qualification as a practical
recommendation rather than a hard limit.

Code

docs/Telemetry.md[236]
+It runs at a fixed baud rate of 115200.

Evidence
The PR removes the SoftSerial 19200-limit wording in Telemetry.md, but Serial.md and Blackbox.md
still assert a 19200 limit. The SoftSerial driver configures its timer period from the requested
baud and does not show an explicit 19200 maximum clamp, so leaving a hard-limit statement elsewhere
is inconsistent with the codebase and with the updated Telemetry.md.
docs/Telemetry.md[205-236]
docs/Serial.md[36-49]
docs/Blackbox.md[68-76]
src/main/drivers/serial_softserial.c[170-189]
src/main/drivers/serial_softserial.c[204-345]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`docs/Telemetry.md` no longer states SoftSerial is limited to 19200 baud, but `docs/Serial.md` and `docs/Blackbox.md` still state (as a hard limit) that SoftSerial is limited to 19200. This creates contradictory documentation after this PR.
### Issue Context
The SoftSerial code path takes a `baud` parameter and configures timers from it without a clear 19200 cap, so documentation that presents 19200 as a strict limit is inconsistent with the current implementation.
### Fix Focus Areas
- docs/Telemetry.md[205-236]
- docs/Serial.md[36-49]
- docs/Blackbox.md[68-76]
- src/main/drivers/serial_softserial.c[170-189]
- src/main/drivers/serial_softserial.c[204-345]
### Suggested change
Update the other docs to match the new reality (e.g., remove the “limited to 19200” hard-limit phrasing) or rephrase consistently as a practical/recommended limit if that’s the intended guidance (e.g., “SoftSerial may be unreliable at high baud rates; prefer hardware UART for >19200 / high bandwidth”).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

4. ~~SoftSerial baud docs conflict~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

This PR removes the “softserial is limit to 19200” note from the iBus telemetry section, but other
docs still state SoftSerial is limited to 19200 baud. This leaves contradictory guidance across the
documentation set and will confuse users configuring SoftSerial-based telemetry/logging.

Code

docs/Telemetry.md[236]

-It runs at a fixed baud rate of 115200, so it need hardware uart (softserial is limit to 19200).
+It runs at a fixed baud rate of 115200.

Evidence
Telemetry.md removed the old SoftSerial=19200 limitation language, but other docs still assert that
limit, creating contradictory guidance.
docs/Telemetry.md[231-237]
docs/Serial.md[46-48]
docs/Blackbox.md[68-75]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
After this PR, `docs/Telemetry.md` no longer mentions a 19200 SoftSerial limit for iBus, but `docs/Serial.md` and `docs/Blackbox.md` still claim SoftSerial is limited to 19200 baud. This is conflicting documentation.
### Issue Context
The PR’s stated goal is to fix misleading SoftSerial-limit docs; this should be applied consistently across the documentation set.
### Fix Focus Areas
- docs/Telemetry.md[231-237]
- docs/Serial.md[46-48]
- docs/Blackbox.md[68-75]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. ~~Softserial limit docs conflict~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

docs/Telemetry.md removes the “softserial limited to 19200” guidance, but other docs still claim
SoftSerial is capped at 19200, creating contradictory configuration guidance. The SoftSerial
implementation appears to accept an arbitrary baud (no explicit 19200 clamp), so the remaining
“19200 limit” statements are likely misleading or at least need qualification as a practical
recommendation rather than a hard limit.

Code

docs/Telemetry.md[236]
+It runs at a fixed baud rate of 115200.

Evidence
The PR removes the SoftSerial 19200-limit wording in Telemetry.md, but Serial.md and Blackbox.md
still assert a 19200 limit. The SoftSerial driver configures its timer period from the requested
baud and does not show an explicit 19200 maximum clamp, so leaving a hard-limit statement elsewhere
is inconsistent with the codebase and with the updated Telemetry.md.
docs/Telemetry.md[205-236]
docs/Serial.md[36-49]
docs/Blackbox.md[68-76]
src/main/drivers/serial_softserial.c[170-189]
src/main/drivers/serial_softserial.c[204-345]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`docs/Telemetry.md` no longer states SoftSerial is limited to 19200 baud, but `docs/Serial.md` and `docs/Blackbox.md` still state (as a hard limit) that SoftSerial is limited to 19200. This creates contradictory documentation after this PR.
### Issue Context
The SoftSerial code path takes a `baud` parameter and configures timers from it without a clear 19200 cap, so documentation that presents 19200 as a strict limit is inconsistent with the current implementation.
### Fix Focus Areas
- docs/Telemetry.md[205-236]
- docs/Serial.md[36-49]
- docs/Blackbox.md[68-76]
- src/main/drivers/serial_softserial.c[170-189]
- src/main/drivers/serial_softserial.c[204-345]
### Suggested change
Update the other docs to match the new reality (e.g., remove the “limited to 19200” hard-limit phrasing) or rephrase consistently as a practical/recommended limit if that’s the intended guidance (e.g., “SoftSerial may be unreliable at high baud rates; prefer hardware UART for >19200 / high bandwidth”).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View medium (2)

6. ~~SoftSerial baud docs conflict~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

This PR removes the “softserial is limit to 19200” note from the iBus telemetry section, but other
docs still state SoftSerial is limited to 19200 baud. This leaves contradictory guidance across the
documentation set and will confuse users configuring SoftSerial-based telemetry/logging.

Code

docs/Telemetry.md[236]

-It runs at a fixed baud rate of 115200, so it need hardware uart (softserial is limit to 19200).
+It runs at a fixed baud rate of 115200.

Evidence
Telemetry.md removed the old SoftSerial=19200 limitation language, but other docs still assert that
limit, creating contradictory guidance.
docs/Telemetry.md[231-237]
docs/Serial.md[46-48]
docs/Blackbox.md[68-75]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
After this PR, `docs/Telemetry.md` no longer mentions a 19200 SoftSerial limit for iBus, but `docs/Serial.md` and `docs/Blackbox.md` still claim SoftSerial is limited to 19200 baud. This is conflicting documentation.
### Issue Context
The PR’s stated goal is to fix misleading SoftSerial-limit docs; this should be applied consistently across the documentation set.
### Fix Focus Areas
- docs/Telemetry.md[231-237]
- docs/Serial.md[46-48]
- docs/Blackbox.md[68-75]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

7. ~~Softserial limit docs conflict~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

docs/Telemetry.md removes the “softserial limited to 19200” guidance, but other docs still claim
SoftSerial is capped at 19200, creating contradictory configuration guidance. The SoftSerial
implementation appears to accept an arbitrary baud (no explicit 19200 clamp), so the remaining
“19200 limit” statements are likely misleading or at least need qualification as a practical
recommendation rather than a hard limit.

Code

docs/Telemetry.md[236]
+It runs at a fixed baud rate of 115200.

Evidence
The PR removes the SoftSerial 19200-limit wording in Telemetry.md, but Serial.md and Blackbox.md
still assert a 19200 limit. The SoftSerial driver configures its timer period from the requested
baud and does not show an explicit 19200 maximum clamp, so leaving a hard-limit statement elsewhere
is inconsistent with the codebase and with the updated Telemetry.md.
docs/Telemetry.md[205-236]
docs/Serial.md[36-49]
docs/Blackbox.md[68-76]
src/main/drivers/serial_softserial.c[170-189]
src/main/drivers/serial_softserial.c[204-345]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`docs/Telemetry.md` no longer states SoftSerial is limited to 19200 baud, but `docs/Serial.md` and `docs/Blackbox.md` still state (as a hard limit) that SoftSerial is limited to 19200. This creates contradictory documentation after this PR.
### Issue Context
The SoftSerial code path takes a `baud` parameter and configures timers from it without a clear 19200 cap, so documentation that presents 19200 as a strict limit is inconsistent with the current implementation.
### Fix Focus Areas
- docs/Telemetry.md[205-236]
- docs/Serial.md[36-49]
- docs/Blackbox.md[68-76]
- src/main/drivers/serial_softserial.c[170-189]
- src/main/drivers/serial_softserial.c[204-345]
### Suggested change
Update the other docs to match the new reality (e.g., remove the “limited to 19200” hard-limit phrasing) or rephrase consistently as a practical/recommended limit if that’s the intended guidance (e.g., “SoftSerial may be unreliable at high baud rates; prefer hardware UART for >19200 / high bandwidth”).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

8. ~~MAVLink sentence punctuation~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The new sentence “transmit-only, is usable…” is a comma splice and reads ambiguously. This reduces
clarity in the updated documentation.

Code

docs/Telemetry.md[209]

+MAVLink implementation in INAV is transmit-only, is usable at low baud rates. MAVLink V1 and V2 are supported.

Evidence

The awkward punctuation is introduced by the new sentence added in Telemetry.md.

docs/Telemetry.md[205-210]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The updated MAVLink line uses a comma splice (“transmit-only, is usable”), which is grammatically awkward and can be misread.
### Issue Context
This is purely a documentation clarity/readability fix.
### Fix Focus Areas
- docs/Telemetry.md[205-210]
### Suggested change
Reword to something like:
- “MAVLink implementation in INAV is transmit-only and usable at low baud rates. MAVLink V1 and V2 are supported.”

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

9. ~~MAVLink sentence punctuation~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The new sentence “transmit-only, is usable…” is a comma splice and reads ambiguously. This reduces
clarity in the updated documentation.

Code

docs/Telemetry.md[209]

+MAVLink implementation in INAV is transmit-only, is usable at low baud rates. MAVLink V1 and V2 are supported.

Evidence

The awkward punctuation is introduced by the new sentence added in Telemetry.md.

docs/Telemetry.md[205-210]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The updated MAVLink line uses a comma splice (“transmit-only, is usable”), which is grammatically awkward and can be misread.
### Issue Context
This is purely a documentation clarity/readability fix.
### Fix Focus Areas
- docs/Telemetry.md[205-210]
### Suggested change
Reword to something like:
- “MAVLink implementation in INAV is transmit-only and usable at low baud rates. MAVLink V1 and V2 are supported.”

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

10. ~~MAVLink sentence punctuation~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The new sentence “transmit-only, is usable…” is a comma splice and reads ambiguously. This reduces
clarity in the updated documentation.

Code

docs/Telemetry.md[209]

+MAVLink implementation in INAV is transmit-only, is usable at low baud rates. MAVLink V1 and V2 are supported.

Evidence

The awkward punctuation is introduced by the new sentence added in Telemetry.md.

docs/Telemetry.md[205-210]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The updated MAVLink line uses a comma splice (“transmit-only, is usable”), which is grammatically awkward and can be misread.
### Issue Context
This is purely a documentation clarity/readability fix.
### Fix Focus Areas
- docs/Telemetry.md[205-210]
### Suggested change
Reword to something like:
- “MAVLink implementation in INAV is transmit-only and usable at low baud rates. MAVLink V1 and V2 are supported.”

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Tip of the day

💡 Did you know, you can enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

qodo-free-for-open-source-projects · 2026-08-08T15:53:23Z

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 📜 Skill insights (0)

1. MAVLink not transmit-only 🐞 Bug ≡ Correctness ⭐ New

Description

docs/Telemetry.md states MAVLink in INAV is “transmit-only”, but the current MAVLink telemetry
implementation reads and processes incoming MAVLink messages (missions/params/RC override/etc). This
misleads users about MAVLink capabilities and is in-scope because the PR edited this sentence but
kept the incorrect claim.

Code

docs/Telemetry.md[209]

+MAVLink implementation in INAV is transmit-only, is usable at low baud rates. MAVLink V1 and V2 are supported.

Evidence
The documentation explicitly claims transmit-only, while the implementation explicitly reads from
the MAVLink serial port and handles multiple incoming message types, so the doc statement is
incorrect.
docs/Telemetry.md[205-210]
src/main/telemetry/mavlink.c[1388-1433]
src/main/telemetry/mavlink.c[1444-1456]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`docs/Telemetry.md` says MAVLink is transmit-only, but the implementation processes inbound MAVLink messages. This is incorrect documentation and can lead users to wrong configuration/expectations.

### Issue Context
The telemetry MAVLink code contains an explicit receive loop and dispatches received message IDs.

### Fix Focus Areas
- docs/Telemetry.md[205-210]
- src/main/telemetry/mavlink.c[1388-1433]
- src/main/telemetry/mavlink.c[1444-1456]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. SoftSerial baud docs conflict 🐞 Bug ⚙ Maintainability ⭐ New

Description

This PR removes the “softserial is limit to 19200” note from the iBus telemetry section, but other
docs still state SoftSerial is limited to 19200 baud. This leaves contradictory guidance across the
documentation set and will confuse users configuring SoftSerial-based telemetry/logging.

Code

docs/Telemetry.md[236]

-It runs at a fixed baud rate of 115200, so it need hardware uart (softserial is limit to 19200).
+It runs at a fixed baud rate of 115200.

Evidence
Telemetry.md removed the old SoftSerial=19200 limitation language, but other docs still assert that
limit, creating contradictory guidance.
docs/Telemetry.md[231-237]
docs/Serial.md[46-48]
docs/Blackbox.md[68-75]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
After this PR, `docs/Telemetry.md` no longer mentions a 19200 SoftSerial limit for iBus, but `docs/Serial.md` and `docs/Blackbox.md` still claim SoftSerial is limited to 19200 baud. This is conflicting documentation.

### Issue Context
The PR’s stated goal is to fix misleading SoftSerial-limit docs; this should be applied consistently across the documentation set.

### Fix Focus Areas
- docs/Telemetry.md[231-237]
- docs/Serial.md[46-48]
- docs/Blackbox.md[68-75]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Softserial limit docs conflict 🐞 Bug ⚙ Maintainability

Description

docs/Telemetry.md removes the “softserial limited to 19200” guidance, but other docs still claim
SoftSerial is capped at 19200, creating contradictory configuration guidance. The SoftSerial
implementation appears to accept an arbitrary baud (no explicit 19200 clamp), so the remaining
“19200 limit” statements are likely misleading or at least need qualification as a practical
recommendation rather than a hard limit.

Code

docs/Telemetry.md[236]
+It runs at a fixed baud rate of 115200.

Evidence
The PR removes the SoftSerial 19200-limit wording in Telemetry.md, but Serial.md and Blackbox.md
still assert a 19200 limit. The SoftSerial driver configures its timer period from the requested
baud and does not show an explicit 19200 maximum clamp, so leaving a hard-limit statement elsewhere
is inconsistent with the codebase and with the updated Telemetry.md.
docs/Telemetry.md[205-236]
docs/Serial.md[36-49]
docs/Blackbox.md[68-76]
src/main/drivers/serial_softserial.c[170-189]
src/main/drivers/serial_softserial.c[204-345]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`docs/Telemetry.md` no longer states SoftSerial is limited to 19200 baud, but `docs/Serial.md` and `docs/Blackbox.md` still state (as a hard limit) that SoftSerial is limited to 19200. This creates contradictory documentation after this PR.
### Issue Context
The SoftSerial code path takes a `baud` parameter and configures timers from it without a clear 19200 cap, so documentation that presents 19200 as a strict limit is inconsistent with the current implementation.
### Fix Focus Areas
- docs/Telemetry.md[205-236]
- docs/Serial.md[36-49]
- docs/Blackbox.md[68-76]
- src/main/drivers/serial_softserial.c[170-189]
- src/main/drivers/serial_softserial.c[204-345]
### Suggested change
Update the other docs to match the new reality (e.g., remove the “limited to 19200” hard-limit phrasing) or rephrase consistently as a practical/recommended limit if that’s the intended guidance (e.g., “SoftSerial may be unreliable at high baud rates; prefer hardware UART for >19200 / high bandwidth”).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

4. MAVLink sentence punctuation 🐞 Bug ⚙ Maintainability

Description

The new sentence “transmit-only, is usable…” is a comma splice and reads ambiguously. This reduces
clarity in the updated documentation.

Code

docs/Telemetry.md[209]

+MAVLink implementation in INAV is transmit-only, is usable at low baud rates. MAVLink V1 and V2 are supported.

Evidence

The awkward punctuation is introduced by the new sentence added in Telemetry.md.

docs/Telemetry.md[205-210]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The updated MAVLink line uses a comma splice (“transmit-only, is usable”), which is grammatically awkward and can be misread.
### Issue Context
This is purely a documentation clarity/readability fix.
### Fix Focus Areas
- docs/Telemetry.md[205-210]
### Suggested change
Reword to something like:
- “MAVLink implementation in INAV is transmit-only and usable at low baud rates. MAVLink V1 and V2 are supported.”

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

sensei-hacker · 2026-08-16T17:54:13Z

Just an FYI for contributors: The tentative schedule for INAV 10 is to have a full release in mid December. That means RC2 needs to be in early to mid November, which places INAV 10.0RC1 at September 1. Please plan to have any new features for INAV 10.0 ready for RC1 no later than September 1. After that, 10.1 will follow about six to seven months later.

Remove the outdated "softserial is limited to 19200" claim: there is no hard baud cap in serial_softserial.c (the baud table extends to 2470000), but softserial is bit-banged, so low rates remain the reliable choice. Fix the "buad" typo and align Serial.md, Telemetry.md and Blackbox.md. Correct the MAVLink description: INAV's MAVLink implementation is bidirectional (it parses inbound messages such as RADIO_STATUS), not transmit-only; fix the comma splice and note softserial usability.

sensei-hacker · 2026-08-30T21:29:00Z

AI review — expanded + retargeted ✅

Thanks RomanLut — the direction was right, so I expanded the cleanup and retargeted the base. Now: base maintenance-10.x, milestone 10.0, 3 files, +4/−4.

What changed (verified against code)

Softserial baud: there is no hard 19200 cap in serial_softserial.c (the serial.c baud table runs to 2470000; the timer timebase computes any requested baud). Softserial is bit-banged, so low rates are the reliable choice — stated that way instead of "limited to 19200". Also fixed the "buad" typo. Aligned Serial.md, Telemetry.md, and Blackbox.md (which carried the same claim).
MAVLink is no longer transmit-only: mavlink_runtime.c parses inbound bytes (while (serialRxBytesWaiting(...) > 0) + mavlink_parse_char), and fc_mavlink.c decodes incoming RADIO_STATUS (link stats). Rewrote the sentence to say "bidirectional", fixed the comma splice, and noted it works at low baud rates / over softserial.
iBus: kept the fixed-115200 fact, added back the accurate consequence (requires a hardware UART).

Base retarget is clean (the branch's merge-base is an ancestor of maintenance-10.x — GitHub diff shows exactly these 3 files). CI test green, MERGEABLE/CLEAN.

update docs

17f7a27

qodo-code-review Bot reviewed Aug 8, 2026

View reviewed changes

Comment thread docs/Telemetry.md Outdated

Comment thread docs/Telemetry.md Outdated

qodo-free-for-open-source-projects Bot reviewed Aug 8, 2026

View reviewed changes

Comment thread docs/Telemetry.md Outdated

Comment thread docs/Telemetry.md

sensei-hacker added this to the 10.0 milestone Aug 29, 2026

sensei-hacker changed the base branch from master to maintenance-10.x August 30, 2026 21:27

sensei-hacker merged commit 6c24c73 into iNavFlight:maintenance-10.x Aug 30, 2026
1 check passed

Navigation Menu

Uh oh!

update docs - softserial limit - #11771

update docs - softserial limit#11771
sensei-hacker merged 2 commits into
iNavFlight:maintenance-10.xfrom
RomanLut:submit-fix-softserial-docs

RomanLut commented Aug 8, 2026

Uh oh!

github-actions Bot commented Aug 8, 2026

Uh oh!

qodo-code-review Bot commented Aug 8, 2026 •

edited by qodo-free-for-open-source-projects Bot

Loading

Uh oh!

qodo-code-review Bot commented Aug 8, 2026 •

edited by qodo-free-for-open-source-projects Bot

Loading

Uh oh!

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 8, 2026

Uh oh!

Uh oh!

Uh oh!

sensei-hacker commented Aug 16, 2026

Uh oh!

sensei-hacker commented Aug 30, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

RomanLut commented Aug 8, 2026

Uh oh!

github-actions Bot commented Aug 8, 2026

Branch Targeting Suggestion

Uh oh!

qodo-code-review Bot commented Aug 8, 2026 • edited by qodo-free-for-open-source-projects Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary by Qodo

Uh oh!

qodo-code-review Bot commented Aug 8, 2026 • edited by qodo-free-for-open-source-projects Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 8, 2026

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

sensei-hacker commented Aug 16, 2026

Uh oh!

sensei-hacker commented Aug 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

AI review — expanded + retargeted ✅

What changed (verified against code)

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

qodo-code-review Bot commented Aug 8, 2026 •

edited by qodo-free-for-open-source-projects Bot

Loading

qodo-code-review Bot commented Aug 8, 2026 •

edited by qodo-free-for-open-source-projects Bot

Loading

sensei-hacker commented Aug 30, 2026 •

edited

Loading